Upgrading sqlglot without upgrading sqlglotc currently breaks silently: the stale compiled
tokenizer_core extension shadows the newer tokenizer_core.py, so the compiled TokenType enum
lacks newly added members while the pure (never-compiled) tokens.py references them. The result is
an import-time crash whose message on Python ≤ 3.11 is just the bare member name, e.g.
AttributeError: LLRR_ARROW after <<->> support landed in v30.9.0 — reproducible with
sqlglot==30.10.0 + sqlglotc==30.8.0 on Python 3.11.

The coupling today is one-directional: the sqlglotc=={version} pin only lives in sqlglot's [c]
extra, and pip does not remember extras on upgrade, so pip install -U sqlglot leaves an old
sqlglotc behind.

This makes the pin bidirectional by having sqlglotc declare sqlglot==<its own version> in its
metadata:

• CI wheel/sdist builds resolve the version from git via setuptools-scm (exact at release tags)
• Rebuilds from a published sdist (no git) read the frozen version from PKG-INFO
• Dev builds (.dev versions) skip the pin, since no matching sqlglot release exists on PyPI;
  local development uses build_ext --inplace and never installs the dist anyway

With this, resolvers keep the two packages in lockstep: uv/poetry refuse to create a skewed
environment, and pip surfaces a clear conflict naming both packages instead of a cryptic one-word
AttributeError at import time.

Verified by generating metadata through setup.py egg_info for both branches: a git checkout at a
dev version emits no pin, and a simulated sdist rebuild emits sqlglot==30.10.0 in requires.txt.